\section{Introducción}

\subsection{Objetivos del trabajo práctico}

En el presente trabajo práctico se nos planteó la tarea de 
analizar una problemática expresada coloquialmente por los agentes afectados y traducirla a
una serie de diagramas que detallen el contexto y los objetivos del sistema a
desarrollar como solución. 
En el proceso, tal como si fueramos un grupo de trabajo en la industria,
se nos presentó la necesidad de tomar decisiones 
para resolver las ambigüedades que presentaba el enunciado, y de interactuar
con un ``tutor'' que nos ayudó haciendo las veces de ``cliente'' y respondiendo
algunas de las dudas que nos iban surgiendo en la búsqueda de un modelo formal.


 En esta situación, los problemas a resolver no se
encuentran pre-procesados y listos para implementar, si no que deben ser especificados primero.
En este contexto podemos, entonces, entender al software como una parte de un sistema más grande, en el que entran
en juego entidades de distintos orígenes y objetivos, tales como el cliente y nosotros los desarrolladores,
así como también el contexto en el que se utilizará la tecnología a desarrollar (dispositivos móviles, limitaciones
de conectividad).


En este trabajo práctico, el proceso de creación y desarrollo de los diversos diagramas queda encapsulado a través de
este informe. Sólo se presentará al lector el resultado final y las aclaraciones que se consideren pertinentes para
permitir un entendimiento claro de la resolución por parte del cliente/tutor/corrector.
%% CREO QUE MUCHAS DE ESTAS COSAS MÁS BIEN VAN EN LAS CONCLUSIONES. ALGUNAS LAS
%% PUSE AHÍ, FÍJENSE CÓMO QUIEREN ESCRIBIR LAS QUE FALTAN.
%% - Contacto con problema no estandarizado/académico.
%% - Toma de decisiones como grupo de trabajo para satisfacer las necesidades de una entidad ajena al mismo.
%% - Consenso entre optimalidad de resolución y conflictos con contexto (por ej., Internet se puede caer).
%% - Necesidad de uso de modelos para comunicarse cross-mundo desarrollador/cliente.
%% - Reconocimiento de las distintas maneras de encarar una propuesta (por ej., a través de sus objetivos o de los agentes involucrados).

\subsection{Modelado}

Para el modelado de la resolución que propongamos al problema presentado, se nos propuso 
utilizar el Modelo de Agentes, plasmado a través de un diagrama de contexto, y el Modelo de Objetivos, 
expresado por medio de un grafo de refinamientos Y/O. Esto nos permite introducirnos
al desarrollo de software directamente desde su contexto el mundo real, en lugar de comenzar pensando directamente 
desde una perspectiva implementativa (que es lo que un programador suele hacer).

Se utilizará el diagrama de agentes para reflejar en qué lugar está parado el sistema a desarrollar y como son
las relaciones entre entidades que están atadas a él o influyen directamente en el funcionamiento del mismo.
Información al respecto de quién debe poder usar qué partes del sistema, qué información se le debe proveer
al mismo y cómo se relacionan las partes involucradas entre sí son las distintas cosas que nos brindan este tipo de
esquemas.

El foco en los diagramas de agentes esta puesto los agentes involucrados en el problema que se desea modelar
y qué tipo de relaciones mantienen entre sí. No resulta útil para, por ejemplo, entender como se ejecutan 
esas relaciones o qué cosas puntuales realizan los agentes íntegramente. 
Es una abstracción del problema a nivel de ``quién está" y ``qué lugar ocupa en el proceso".

Por otro lado, utilizamos el grafo de refinamiento de objetivos para reflejar más formalmente lo que se nos cuenta de manera vaga 
sobre la solución buscada. Entre otras cosas, en el grafo se escriben las condiciones que se deben cumplir para considerar que el sistema que estamos modelando funciona como se requiere. Los objetivos extraídos de la información provista por el cliente se refinan en subobjetivos 
de menor grado de complejidad, hasta el punto de poder asignarle los subobjetivos a una entidad, o decidir que son condiciones del ambiente. 
Cuando la asignacion objetivo-agente involucra al sistema que estamos por desarrollar, decimos que estamos ante una expectativa sobre el sistema.

Es importante notar que en este tipo de diagrama se busca listar todos los objetivos que el cliente espera que cumpla el sistema,
 centrado en qué es lo que se quiere lograr y no en cómo hacerlo. No es el fin de los diagramas de objetivos develar detalles de implementación
sobre cómo alcanzar los distintos objetivos; debe proveer únicamente información sobre qué condiciones deben cumplirse para alcanzar cada
uno de ellos. Es importante notar que las presunciones del dominio en el que existe el sistema resultan vitales para la forma en que
se plantean y conectan los objetivos, puesto que no hay forma de modelar una solución que salve las infinitas posibilidades
 que se nos presentan en el mundo real frente a cada situación.



%% - Específicamente por qué usamos contexto y objetivos (más allá de "porque era la consigna").
%% - Puntos fuertes de ambos.
%% - Puntos débiles de ambos (por ej., cosas que no nos muestran).
%% - Interpretación de las inquietudes como objetivos que el sistema debe cumplir.
%% - Necesidad de integrar el sistema con el contexto para el que se quiere
%% desarrollar.

